.. _rfc8866: RFC8866: SDP-Session Description Protocol ######################################### * Obsoletes: `rfc4566(July 2006)` `rfc2327(April 1998)` `rfc3266(June 2002)` * Category: Standards Track * January 2021 * SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. 1. Introduction =============== * When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants. * SDP provides a standard representation for such information, irrespective of how that information is transported. * It is intended to use different transport protocols as appropriate, including the `Session Announcement Protocol(SAP)[RFC2974] `_, `Session Initiation Protocol(SIP)[RFC3261] `_ , `Real-Time Streaming Protocol (RTSP) [RFC7826] `_, ``electronic mail [RFC5322] using the MIME extensions [RFC2045]``, and the ``Hypertext Transport Protocol (HTTP) [RFC7230]``. * SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. 2. Glossary of Terms ==================== * Session Description: A well-defined format for conveying sufficient information to discover and participate in a multimedia session. * Media Description: A Media Description contains the information needed for one party to establish an application-layer network protocol connection to another party. It starts with an "m=" line and is terminated by either the next "m=" line or by the end of the session description. * Session-Level Section: This refers to the parts that are not media descriptions, => whereas the ``session description`` refers to the whole body that includes the ``session-level section`` and the ``media description(s)``. 3. Examples of SDP Usage ======================== 3.1. Session Initiation ----------------------- * The Session Initiation Protocol (SIP) [RFC3261] is an application-layer control protocol for creating, modifying, and terminating sessions such as Internet multimedia conferences, Internet telephone calls, and multimedia distribution. * The SIP messages used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types [RFC6838]. 3.2. Streaming Media -------------------- * The Real-Time Streaming Protocol (RTSP) [RFC7826], is an application-level protocol for control over the delivery of data with real-time properties. * RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. * An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters. 3.3. Email and the World Wide Web --------------------------------- * For both email and WWW distribution, the media type "application/sdp" is used. 3.4. Multicast Session Announcement ----------------------------------- * One protocol used to implement such a distributed directory is the SAP [RFC2974]. * SDP provides the recommended session description format for such session announcements. 4. Requirements and Recommendations =================================== * The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. An SDP description includes the following:: 1. Session name and purpose 2. Time(s) the session is active 3. The media comprising the session 4. Information needed to receive those media (addresses, ports, formats, etc.) * In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys) and to announce the resources to be used to any nonparticipants that may need to know. (This latter feature is primarily useful when SDP is used with a multicast session announcement protocol.) 4.1. Media and Transport Information ------------------------------------ An SDP description includes the following media information:: 1. The type of media (video, audio, etc.) 2. The media transport protocol (RTP/UDP/IP, H.320, etc.) 3. The format of the media (H.261 video, MPEG video, etc.) 4. Typically, the remote address and remote port 4.2. Timing Information ----------------------- * Sessions may be either bounded or unbounded in time. * Whether or not they are bounded, they may be only active at specific times. SDP can convey:: An arbitrary list of start and stop times bounding the session For each bound, repeat times such as "every Wednesday at 10am for one hour" 5. SDP Specification -------------------- * An SDP description is denoted by the media type "application/sdp" (See Section 8). * An SDP description is entirely textual. An SDP description consists of a number of lines of text of the form:: = .. note:: Some lines in each description are required and some are optional, but when present, they must appear in exactly the order given here. (The fixed order greatly enhances error detection and allows for a simple parser). An SDP description consists of a ``session-level section`` followed by zero or more ``media descriptions``:: 注: optional items are marked with a "*" Session description v= (protocol version) o= (originator and session identifier) s= (session name) i=* (session information) u=* (URI of description) e=* (email address) p=* (phone number) c=* (connection information -- not required if included in all media descriptions) b=* (zero or more bandwidth information lines) One or more time descriptions: ("t=", "r=" and "z=" lines; see below) k=* (obsolete) a=* (zero or more session attribute lines) Zero or more media descriptions Time description t= (time the session is active) r=* (zero or more repeat times) z=* (optional time zone offset line) Media description, if present m= (media name and transport address) i=* (media title) c=* (connection information -- optional if included at session level) b=* (zero or more bandwidth information lines) k=* (obsolete) a=* (zero or more media attribute lines) An example SDP description is:: v=0 o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1 s=Call to John Smith i=SDP Offer #1 u=http://www.jdoe.example.com/home.html e=Jane Doe p=+1 617 555-6011 c=IN IP4 198.51.100.1 t=0 0 m=audio 49170 RTP/AVP 0 m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 c=IN IP6 2001:db8::2 a=rtpmap:99 h263-1998/90000 5.1. Protocol Version ("v=") ---------------------------- * The "v=" line (version-field) gives the version of the Session Description Protocol. * This memo defines version 0 means there is no minor version number. 示例:: v=0 5.2. Origin ("o=") ------------------ * In general, the "o=" line serves as a globally unique identifier for this version of the session description, and the subfields excepting the version, taken together identify the session irrespective of any modifications. 格式:: o= 说明:: The user's login on the originating host, or it is "-" if the originating host does not support the concept of user IDs. The MUST NOT contain spaces. a numeric string such that the tuple of , , , , and forms a globally unique id for the session. The method of allocation is up to the creating tool, but a timestamp, in seconds since January 1, 1900 UTC, is recommended to ensure uniqueness. a version number for this session description. Its usage is up to the creating tool, so long as is increased when a modification is made to the session description. Again, as with it is RECOMMENDED that a timestamp be used. a text string giving the type of network. Initially, "IN" is defined to have the meaning "Internet", but other values MAY be registered in the future (see Section 8). a text string giving the type of the address that follows. Initially, "IP4" and "IP6" are defined, but other values MAY be registered in the future (see Section 8). an address of the machine from which the session was created. For an address type of "IP4", this is either a fully qualified domain name of the machine or the dotted-decimal representation of an IP version 4 address of the machine. For an address type of "IP6", this is either a fully qualified domain name of the machine or the address of the machine represented as specified in Section 4 of [RFC5952]. For both "IP4" and "IP6", the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case a globally unique address MAY be substituted. 5.3. Session Name ("s=") ------------------------ 格式:: s= * The "s=" line (session-name-field) is the textual session name. * There MUST be one and only one "s=" line per session description. * The "s=" line MUST NOT be empty. If a session has no meaningful name, then "s= " or "s=-" (i.e., a single space or dash as the session name) is RECOMMENDED. 5.4. Session Information ("i=") ------------------------------- 格式:: i= * The "i=" line (information-field) provides textual information about the session. 5.5. URI ("u=") --------------- 格式:: u= * The "u=" line (uri-field) provides a URI (Uniform Resource Identifier) [RFC3986]. 5.6. Email Address and Phone Number ("e=" and "p=") --------------------------------------------------- 格式:: e= p= * The "e=" line (email-field) and "p=" line (phone-field) specify contact information for the person responsible for the session. Example:: p=+1 617 555-6011 e=j.doe@example.com (Jane Doe) e=Jane Doe 5.7. Connection Information ("c=") ---------------------------------- 格式:: c= * The "c=" line (connection-field) contains information necessary to establish a network connection. * A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. 示例:: c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127/3 c=IN IP6 ff00::db8:0:101/3 5.8. Bandwidth Information ("b=") --------------------------------- 格式:: b=: * The OPTIONAL "b=" line (bandwidth-field) denotes the proposed bandwidth to be used by the session or media description. * The is an alphanumeric modifier that provides the meaning of the number. Two values are defined in this specification, but other values MAY be registered in the future:: CT AS 5.9. Time Active ("t=") ----------------------- * A "t=" line (time-field) begins a time description that specifies the start and stop times for a session. 格式:: t= The following example specifies two active intervals:: t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC * These are the decimal representation of time values in seconds since January 1, 1900 UTC. * If the is set to zero, then the session is not bounded, though it will not become active until after the . If the is also zero, the session is regarded as permanent. * User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult. 5.10. Repeat Times ("r=") ------------------------- 格式:: r= 示例:: t=3724394400 3730536000 ; Mon 08-Jan-2018 10:00 UTC ; Tue 20-Mar-2018 12:00 UTC r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours times may also be given in units of days, hours, or minutes: r=7d 1h 0 25h 5.11. Time Zone Adjustment ("z=") --------------------------------- 格式:: z= .... * To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify ``offsets`` from the base time. An example might be the following:: t=3724394400 3754123200 ; Mon 08-Jan-2018 10:00 UTC ; Tue 18-Dec-2018 12:00 UTC r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC, ; offset 1 hour, ; Sun 28-Oct-2018 2:00 UTC, ; no offset * This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the onset of British Summer Time) the time base by which the session's repeat times are calculated is shifted back by 1 hour, and that at time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer Time) the session's original time base is restored. 5.12. Encryption Keys ("k=") ---------------------------- 格式:: k= k=: * The "k=" line (key-field) is obsolete and MUST NOT be used. 5.13. Attributes ("a=") ----------------------- 格式:: a= a=: * Attributes are the primary means for extending SDP. * Attributes may be defined to be used as session-level attributes, media-level attributes, or both. Attribute-fields may be of two forms:: A property attribute is simply of the form "a=". These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session. An example might be "a=recvonly". A value attribute is of the form "a=:". For example, a whiteboard could have the value attribute "a=orient:landscape". 5.14. Media Descriptions ("m=") ------------------------------- 格式:: m= ... * Each media description starts with an "m=" line (media-field) and is terminated by either the next "m=" line or by the end of the session description. A media-field has several subfields:: : the media type. including: "audio" "video" "text" "application" "message" : the transport port to which the media stream is sent. : the transport protocol. including: "udp" "RTP/AVP" "RTP/SAVP" "RTP/SAVPF" ： a media format description. The interpretation of the media format depends on the value of the subfield. If the subfield is "RTP/AVP" or "RTP/SAVP", the subfields contain RTP payload type numbers. If the subfield is "udp", the subfields MUST reference a media type describing the format under the "audio", "video", "text", "application", or "message" top-level media types. 6. SDP Attributes ================= 6.1. cat (Category) ------------------- Syntax:: cat-value = category category = non-ws-string Example:: a=cat:foo.bar * This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received. 6.2. keywds (Keywords) ---------------------- Syntax:: keywds-value = keywords keywords = text Example:: a=keywds:SDP session description protocol * This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received. 6.3. tool --------- * This gives the name and version number of the tool used to create the session description. Syntax:: tool-value = tool-name-and-version tool-name-and-version = text Example:: a=tool:foobar V3.2 6.4. ptime (Packet Time) ------------------------ * This gives the length of time in milliseconds represented by the media in a packet. * This is probably only meaningful for audio data, but may be used with other media types if it makes sense. * It should not be necessary to know "a=ptime:" to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetization of audio. Syntax:: ptime-value = non-zero-int-or-real Example:: a=ptime:20 6.5. maxptime (Maximum Packet Time) ----------------------------------- * This gives the maximum amount of media that can be encapsulated in each packet, expressed as time in milliseconds. * The time SHALL be calculated as the sum of the time the media present in the packet represents. * a=ptime指定了每个packet的标准payload时长,但实际上每个packet的payload长度可能会有些变化。a=maxptime则指定了最大允许的payload时长变化。 * 通过设置maxptime,接收端可以预留足够的缓存空间,以防实际的packet payload长度超出正常的ptime设置。这也有助于避免数据包溢出和丢包。所以a=ptime和a=maxptime一起使用,可以让发送端和接收端对RTP数据包中的音视频数据具有更精确和更健壮的处理能力。 Syntax:: maxptime-value = non-zero-int-or-real Example:: a=maxptime:20 6.6. rtpmap ----------- * This attribute maps from an RTP payload type number (as used in an "m=" line) to an encoding name denoting the payload format to be used. * Note that the payload type number is indicated in a 7-bit field, limiting the values to inclusively between 0 and 127. Syntax:: rtpmap-value = payload-type SP encoding-name "/" clock-rate [ "/" encoding-params ] payload-type = zero-based-integer encoding-name = token clock-rate = integer encoding-params = channels channels = integer If we wish to use the dynamic RTP/AVP payload type 98 for this stream, additional information is required to decode it:: m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 Up to one "a=rtpmap:" attribute can be defined for each media format specified. Thus, we might have the following:: m=audio 49230 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 自有摄像头实例:: m=audio 0 RTP/AVP 8 a=rtpmap:8 PCMA/8000/1 m=video 0 RTP/AVP 96 a=rtpmap:96 H264/90000 常见的Payload Type值为:: 0: PCMU - G.711 u-law 64kbit/s audio 1: 1016 - G.721 ADPCM 32kbit/s audio 3: GSM - GSM 06.10 13kbit/s audio 4: G723 - G.723.1 dual rate 5.3/6.3kbit/s audio 5: DVI4 - IMA ADPCM 32kbit/s audio 6: DVI4 - IMA ADPCM 64kbit/s audio 7: LPC - LPC-10 2.5kbit/s audio 8: PCMA - G.711 A-law 64kbit/s audio 9: G722 - G.722 64kbit/s audio 10: L16 - Linear PCM 44.1kHz audio 11: L16 - Linear PCM 44.1kHz stereo audio 12: QCELP - QCELP 8kbit/s audio 13: CN - Comfort noise 8kbit/s audio 14: MPA - MPEG-1/MPEG-2 audio 15: G728 - G.728 16kbit/s audio 16-23: - Unassigned 24: unassigned video 25: CelB - Sun CellB video 26: JPEG - JPEG video 28: nv - nv video 31: H261 - H.261 video 32: MPV - MPEG-1/MPEG-2 video 33: MP2T - MPEG-2 transport stream 34: H263 - H.263 video 96-127: - Dynamic range 6.7. Media Direction Attributes ------------------------------- * At most one occurrence of "a=recvonly", "a=sendrecv", "a=sendonly", or "a=inactive" MAY appear at session level, and at most one MAY appear in each media description. .. note:: If none of the media direction attributes is present at either session level or media level, "a=sendrecv" SHOULD be assumed as the default. Within the following SDP example, the "a=sendrecv" attribute applies to the first audio media and the "a=inactive" attribute applies to the others:: v=0 o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1 s=- c=IN IP6 2001:db8::1 t=0 0 a=inactive m=audio 49170 RTP/AVP 0 a=sendrecv m=audio 49180 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000 说明:: a=recvonly 表示这个流只能被接收,不能被发送。接收端可以获取媒体数据,但发送端不发送任何数据。 a=sendrecv 表示这个流可以双向传输,既可以发送也可以接收。这是最常见的流方向。 a=sendonly 表示这个流只能被发送,不能被接收。发送端发送媒体数据,但接收端不接收任何数据。 a=inactive 表示这个流暂时不活动,既不发送也不接收任何数据。 通过指定不同的方向,可以实现 more 复杂的交互,比如:: - 发送端发送,多个接收端接收(单播或多播) - 多个发送端发送,接收端选择性接收 - 先发送后接收,实现“询问”的效果 - 先接收用户输入,后发送响应信息 典型场景如下:: a=recvonly - 监控摄像头:多个客户端接收同一个摄像头的视频流 - 直播:观众接收流媒体服务器的音视频流 a=sendrecv - 视频聊天:双方互相发送和接收音视频流 - 在线会议:多方互相发送和接收视频和音频 a=sendonly - 直播:流媒体服务器向观众发送流,但不接收任何流 - 摄像头:IP摄像头发送视频流,但不接收任何流 a=inactive - 流暂时不活动,可能由于网络问题或客户端的请求。等情况恢复后可以重新变为 sendrecv 或 recvonly 这4种属性基本上涵盖了流媒体的所有应用场景:: - 点对点:视频聊天(sendrecv) - 点对多点:监控、在线课堂(recvonly) - 多点对多点:视频会议(sendrecv) - 直播:IP摄像头、直播节目(sendonly) 6.7.1. recvonly (Receive-Only) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * This specifies that the tools should be started in receive-only mode where applicable. * Note that receive-only mode applies to the media only, not to any associated control protocol. Example:: a=recvonly 6.7.2. sendrecv (Send-Receive) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Example:: a=sendrecv * This specifies that the tools should be started in send and receive mode. * This is necessary for interactive multimedia conferences with tools that default to receive-only mode. 6.7.3. sendonly (Send-Only) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Example:: a=sendonly * This specifies that the tools should be started in send-only mode. * An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. * In such a case, two media descriptions may be used, one in send-only mode and one in receive-only mode. * Note that send-only mode applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal. 6.7.4. inactive ^^^^^^^^^^^^^^^ Example:: a=inactive * This specifies that the tools should be started in inactive mode. * This is necessary for interactive multimedia conferences where users can put other users on hold. * No media is sent over an inactive media stream. * Note that an RTP-based system MUST still send RTCP (if RTCP is used), even if started in inactive mode. 6.8. orient (Orientation) ------------------------- Syntax:: orient-value = portrait / landscape / seascape portrait = %s"portrait" landscape = %s"landscape" seascape = %s"seascape" ; NOTE: These names are case-sensitive. Example:: a=orient:portrait * Normally this is only used for a whiteboard or presentation tool. * It specifies the orientation of the workspace on the screen. * Permitted values are "portrait", "landscape", and "seascape" (upside-down landscape). 6.9. type (Conference Type) --------------------------- Syntax:: type-value = conference-type conference-type = broadcast / meeting / moderated / test / H332 broadcast = %s"broadcast" meeting = %s"meeting" moderated = %s"moderated" test = %s"test" H332 = %s"H332" ; NOTE: These names are case-sensitive. Example:: a=type:moderated * This specifies the type of the multimedia conference. 6.10. charset (Character Set) ----------------------------- * By default, the ISO-10646 character set in UTF-8 encoding is used. * If a more compact representation is required, other character sets may be used. * The charset specified MUST be one of those registered in the IANA Character Sets registry (http://www.iana.org/assignments/character-sets) Syntax:: charset-value = For example, the ISO 8859-1 is specified with the following SDP attribute::: a=charset:ISO-8859-1 6.11. sdplang (SDP Language) ---------------------------- Syntax:: sdplang-value = Language-Tag ; Language-Tag defined in RFC 5646 Example:: a=sdplang:fr * In general, sending session descriptions consisting of multiple languages is discouraged. * The "a=sdplang:" attribute value must be a single language tag [RFC5646]. 6.12. lang (Language) --------------------- * The "a=lang:" attribute is supposed to be used for setting the initial language(s) used in the session. Syntax:: lang-value = Language-Tag ; Language-Tag defined in RFC 5646 Example:: a=lang:de 6.13. framerate (Frame Rate) ---------------------------- * This gives the maximum video frame rate in frames/sec. * It is intended as a recommendation for the encoding of video data. Decimal representations of fractional values are allowed. * It is defined only for video media. Syntax:: framerate-value = non-zero-int-or-real Example:: a=framerate:60 6.14. quality ------------- Syntax:: quality-value = zero-based-integer Example:: a=quality:10 * This gives a suggestion for the quality of the encoding as an integer value. * The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. * For video, the value is in the range 0 to 10, with the following suggested meaning: Table 2: Encoding Quality Values 10 the best still-image quality the compression scheme can give. 5 the default behavior given no quality suggestion. 0 the worst still-image quality the codec designer thinks is still usable. 6.15. fmtp (Format Parameters) ------------------------------ Syntax:: fmtp-value = fmt SP format-specific-params format-specific-params = byte-string ; Notes: ; - The format parameters are media type parameters and ; need to reflect their syntax. Example:: a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 * This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP does not have to understand them. * The format must be one of the formats specified for the media. * Format-specific parameters, semicolon separated, may be any set of parameters required to be conveyed by SDP and given unchanged to the media tool that will use this format. * At most one instance of this attribute is allowed for each format. 7. Security Considerations ========================== * SDP MUST NOT be used to convey keying material (e.g., using the "a=crypto:" attribute [RFC4568]) unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. 8. IANA Considerations ====================== One media type registration from [RFC4566] has been updated, as defined below. Type name: application Subtype name: sdp Required parameters: None. Optional parameters: None. 9. SDP Grammar ============== SDP Syntax:: session-description = version-field origin-field session-name-field [information-field] [uri-field] *email-field *phone-field [connection-field] *bandwidth-field 1*time-description [key-field] *attribute-field *media-description 通用:: version-field = %s"v" "=" 1*DIGIT CRLF ;this memo describes version 0 origin-field = %s"o" "=" username SP sess-id SP sess-version SP nettype SP addrtype SP unicast-address CRLF session-name-field = %s"s" "=" text CRLF information-field = %s"i" "=" text CRLF uri-field = %s"u" "=" uri CRLF email-field = %s"e" "=" email-address CRLF phone-field = %s"p" "=" phone-number CRLF connection-field = %s"c" "=" nettype SP addrtype SP connection-address CRLF ; a connection field must be present ; in every media description or at the session level bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF time相关:: time-description = time-field [repeat-description] repeat-description = 1*repeat-field [zone-field] time-field = %s"t" "=" start-time SP stop-time CRLF repeat-field = %s"r" "=" repeat-interval SP typed-time 1*(SP typed-time) CRLF zone-field = %s"z" "=" time SP ["-"] typed-time *(SP time SP ["-"] typed-time) CRLF field:: key-field = %s"k" "=" key-type CRLF attribute-field = %s"a" "=" attribute CRLF media-description = media-field [information-field] *connection-field *bandwidth-field [key-field] *attribute-field media-field = %s"m" "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF sub-rules:: ; sub-rules of 'o=' username = non-ws-string ;pretty wide definition, but doesn't ;include space sess-id = 1*DIGIT ;should be unique for this username/host sess-version = 1*DIGIT nettype = token ;typically "IN" addrtype = token ;typically "IP4" or "IP6" ; sub-rules of 'u=' uri = URI-reference ; see RFC 3986 ; sub-rules of 'e=', see RFC 5322 for definitions email-address = address-and-comment / dispname-and-address / addr-spec address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" ; sub-rules of 'p=' phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe "<" phone ">" / phone phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) ; sub-rules of 'c=' connection-address = multicast-address / unicast-address ; sub-rules of 'b=' bwtype = token bandwidth = 1*DIGIT ; sub-rules of 't=' start-time = time / "0" stop-time = time / "0" time = POS-DIGIT 9*DIGIT ; Decimal representation of time in ; seconds since January 1, 1900 UTC. ; The representation is an unbounded ; length field containing at least ; 10 digits. Unlike some representations ; used elsewhere, time in SDP does not ; wrap in the year 2036. ; sub-rules of 'r=' and 'z=' repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit] fixed-len-time-unit = %s"d" / %s"h" / %s"m" / %s"s" ; NOTE: These units are case-sensitive. ; sub-rules of 'k=' key-type = %s"prompt" / %s"clear:" text / %s"base64:" base64 / %s"uri:" uri ; NOTE: These names are case-sensitive. base64 = *base64-unit [base64-pad] base64-unit = 4base64-char base64-pad = 2base64-char "==" / 3base64-char "=" base64-char = ALPHA / DIGIT / "+" / "/" ; sub-rules of 'a=' attribute = (attribute-name ":" attribute-value) / attribute-name attribute-name = token attribute-value = byte-string att-field = attribute-name ; for backward compatibility ; sub-rules of 'm=' media = token ;typically "audio", "video", "text", "image" ;or "application" fmt = token ;typically an RTP payload type for audio ;and video media proto = token *("/" token) ;typically "RTP/AVP", "RTP/SAVP", "udp", ;or "RTP/SAVPF" port = 1*DIGIT generic sub-rules:: ; generic sub-rules: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr multicast-address = IP4-multicast / IP6-multicast / FQDN / extn-addr IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" numaddr ] ; IP4 multicast addresses may be in the ; range 224.0.0.0 to 239.255.255.255 m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT ) IP6-multicast = IP6-address [ "/" numaddr ] ; IP6 address starting with FF numaddr = integer ttl = (POS-DIGIT *2DIGIT) / "0" FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified ; in RFC 1035 (and updates) IP4-address = b1 3("." decimal-uchar) b1 = decimal-uchar ; less than "224" IP6-address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" h16 = 1*4HEXDIG ls32 = ( h16 ":" h16 ) / IP4-address ; Generic for other address families extn-addr = non-ws-string ; generic sub-rules: datatypes text = byte-string ;default is to interpret this as UTF8 text. ;ISO 8859-1 requires "a=charset:ISO-8859-1" ;session-level attribute to be used byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR, or LF non-ws-string = 1*(VCHAR/%x80-FF) ;string of visible characters token-char = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" ; (single quote) / "*" / "+" / "-" / "." / "^" / "_" / "`" ; (Grave accent) / "{" / "|" / "}" / "~" token = 1*(token-char) email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF ;any byte except NUL, CR, LF, or the quoting ;characters ()<> integer = POS-DIGIT *DIGIT zero-based-integer = "0" / integer non-zero-int-or-real = integer / non-zero-real non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT ; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT POS-DIGIT = %x31-39 ; 1 - 9 decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) ; external references: ALPHA = DIGIT = CRLF = HEXDIG = SP = VCHAR = URI-reference = addr-spec = 10. Summary of Changes from RFC 4566 ==================================== * Identified now-obsolete items: "a=cat:" (Section 6.1), "a=keywds:" (Section 6.2), and "k=" (Section 5.12). * Expanded and clarified the specification of the "a=lang:" (Section 6.12) and "a=sdplang:" (Section 6.11) attributes. * Removed some references to SAP because it is no longer in widespread use. * Changed some examples to use IPv6 addresses, and added additional examples using IPv6.